Block diagrams are used to model real-world systems. Historically, engineers and scientists have utilized time-based block diagram models in numerous scientific areas such as Feedback Control Theory and Signal Processing to study, design, debug, and refine dynamic systems. Dynamic systems, which are characterized by the fact that their behaviors change over time, are representative of many real-world systems. A dynamic system (either natural or man-made) is a system whose response at any given time is a function of its input stimuli, its current state, and the current time. Such systems range from simple to highly complex systems. Physical dynamic systems include a falling body, the rotation of the earth, bio-mechanical systems (muscles, joints, etc.), bio-chemical systems (gene expression, protein pathways), and weather and climate pattern systems. Examples of man-made or engineered dynamic systems include: a bouncing ball, a spring with a mass tied on an end, automobiles, airplanes, control systems in major appliances, communication networks, audio signal processing, nuclear reactors, and a stock market.
A block diagram model of a dynamic system is represented schematically as a collection of blocks interconnected by lines that represent signals. A signal represents the input and output of a dynamic system. Each block represents an elemental dynamic system. A line emanating at one block and terminating at another signifies that the output of the first block is an input to the second block. Each distinct input or output on a block is referred to as a port. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant at which the connecting blocks are enabled. The source block of a signal writes to the signal at a given time instant when its system equations are solved. The destination blocks of this signal read from the signal when their system equations are being solved.
Time-based block diagram models may be thought of as relationships between signals and state variables representative of a dynamic system. The solution (computation of system response) of the model is obtained by evaluating these relationships over time. The time-based relationship may start at a user-specified “start time” and end at a user-specified “stop time”, or the evaluations may continue indefinitely. Each evaluation of these relationships is part of a time step. Signals represent quantities that change over time. The relationships between signals and state variables are defined by sets of equations represented by blocks. These equations define a relationship between the input signals, output signals, state, and time.
It should be noted that the term “block diagram” as used herein is also used to refer to other graphical modeling formalisms. For instance, flow-charts are block diagrams of entities that are connected by relations. Flow-charts are used to capture process flow and are not generally suitable for describing dynamic system behavior. Data flow block diagrams are diagrams of entities with relations between them that describe a graphical programming paradigm where the availability of data is used to initiate the execution of blocks, where a block represents an operation and a line represents execution dependency describing the direction of data flowing between blocks. It will be appreciated that a block diagram model may include entities that are based on other modeling domains within the block diagram. A common characteristic among these various forms of block diagrams is that they define semantics on how to execute them.
As noted above, professionals from diverse areas such as engineering, science, education, and economics build computational models of dynamic systems in order to better understand system behavior as it changes with the progression of time. The computational models aid in building “better” systems, where “better” may be defined in terms of a variety of performance measures such as quality, time-to-market, cost, speed, size, power consumption, robustness, etc. The computational models also aid in analyzing, debugging and repairing existing systems (be it the human body or the anti-lock braking system in a car). As systems become more complex, an increasingly large amount of time and effort is involved in creating accurate, detailed models. These models are typically hybrid dynamic systems that span a variety of domains, including continuous dynamics and discrete behavior, physical connections, and event-driven states. To add to the complexity, these systems may be depicted in a number of ways, including dynamic or physics block diagrams, finite state machines, and hand-written or automatically generated computer code.
Historically, software developers have utilized co-simulation technology in the design and testing of software. A proposed algorithm to be implemented on hardware is first simulated in a model environment on a host simulation environment, such as personal computer, workstation or the like. Then, incrementally, portions of the algorithm are translated to software for execution on an external processor platform. An external processor can include devices such as a general purpose processor (GPP), microcontroller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) or some combination thereof. By invoking co-simulation technology the software may be tested and verified in the context of the entire application design. Furthermore, the use of co-simulation technology allows multiple developers to simultaneously work on individual components of the block diagram simulation model. The work of each of these developers on either a single portion of the block diagram model, or distinct portions of the block diagram model can then be incorporated into the block diagram simulation model for further testing and evaluation. Following the incorporation of each of these individual components into the host simulation model, the system performance and characteristics can be further evaluated prior to the construction of the entire application.
Existing co-simulation technology provides for the integration of an external processor into the host side simulation environment in a synchronized way. This synchronization currently requires a peer to peer handshaking arrangement between the host simulation environment and the external processor. From the host side simulation, input parameters are assigned and sent to the external processor and the output of the external processor is retrieved for continued simulation in the host simulation environment.
From the processor side of existing co-simulation technology, the code running on the external processor must be modified to include one or more forced time delays, for example one or more wait loops. For example, code running on the external processor will contain a wait loop or a handshaking means in addition to traditional function calls. The wait loop will run continuously on the external processor waiting for a trigger signal from the host simulation environment. This trigger can take the form of a Boolean flag, for example, and upon receipt of a trigger signal from the host simulation environment, an appropriate driver is called such that the driver can get the required function input from the simulation model. Having received the function input parameters, the execution of a desired function on the external processor can begin. Following the execution of the function on the external processor, the output of the executed function can then be returned to the model environment using a handshaking mechanism between host simulation environment and external processor such that the handshaking mechanism provides a mechanism for communication and data transfer between the simulation environment and the external processor. Handshaking such as this typically occurs following the invoking of processor to host device drivers that allows for communication between the two environments. One such example of conventional co-simulation code is:
Loop—foreverIf triggerCall device driver to get function input from hostCall embedded functionCall device driver to send function output to hostEnd ifEnd loopwherein co-simulation specific code is identified by the use of italics.
As evidenced in the above referenced code, the external processor continually runs the wait loop, forcing a time delay in a portion of the code, in anticipation of a trigger signal from the host simulation environment. Upon receipt of the trigger signal, a device driver is called that retrieves the intended function inputs from the host simulation environment. These intended function inputs are then passed to the called embedded function of the prior example, and in turn, the function executes. Following the execution of the function in the external processor, a device driver is called wherein the device driver is utilized for sending the output of the function to the host simulation environment in support of the co-simulation.
In view of this, existing co-simulation technology results in the creation of two sets of code for running on the external processor. The first set of code, namely a test version, contains a handshaking instruction including device drivers and calls to these device drivers to obtain the function inputs, as well as passing the function outputs back to the host simulation environment. These handshaking instructions run in a perpetual wait loop on the external processor, awaiting an initial trigger from the host simulation environment signaling the need for execution of a function outside the host simulation environment.
A second deployed version of code for use on the external processor is subsequently generated wherein the handshaking instructions and wait loop is no longer necessary for performing co-simulation between the host simulation environment and the external processor. However, testing of this deployed version of code in a co-simulation environment is difficult or impossible, therefore there exists a great potential for code conflicts and unanticipated negative results in the deployed version of the code.